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(54) A programmable telecommunications interface for communication over a data network 



(57) A telecommunications system includes the 
public switched telephone system (PSTN) and a data 
network (6), such as the Internet. Voice over IP (VoIP) 
boards (48) communicate between the PSTN and the 
data network (6) under control of a programmable sen^- 



ice logic execution environment (12). Telephone servic- 
es between and among the Internet (6) and the PSTN 
can be initiated by a JAVA applet. By packetizing the 
PSTN bearer channel, enhances resources can be pro- 
vided, such as sophisticated conferencing, speech-to- 
text, e-mail to voice, and so on. 
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Descripti n 

[OD01] This invention relates in general to telecommu- 
nications and. more particularly, to a programmable tel- 
ecommunications interface. 

[0002] H.323 is a multimedia communications proto- 
col which promises to have a significant impact on many 
multimedia applications, such as videoconferencing, In- 
ternet telephony, conference calling, and gaming, to 
name a few. The H.323 standard provides support for 
audio and video over IP (Internet Protocol) based net- 
works, as well as for data communications. The Internet 
is one such data network which will benefit from H.323. 
[0003] H.323 provides compatibility between devices 
which would otherwise be subject to proprietary solu- 
tions. For example, H.323 specifies standards for audio/ 
video compression and decompression and for commu- 
nicating device capabilities, common call setup and call 
control. H.323 supports conferences of three or more 
endpoints without required use of a multipoint control 
unit and supports multicast transport in multipoint con- 
ferences. Further, the bandwidth of audio and video 
streams can be managed by network managers. 
[0004] Despite the advantages of H.323 devices, is- 
sues remain. In order to support an H.323 compliant net- 
work, a number of communications devices must be de- 
signed. Rapid service development and deployment of 
these devices is therefore an important challenge to the 
communications industry. Further, like many standards, 
H.323 will likely evolve over time or may be supplanted 
by other protocols. In either case, reprogramming the 
H.323 devices could be extremely costly and time con- 
suming. 

[0005] Further, while H.323 provides protocols for 
communications over a data network, digital telephone 
remains primitive and difficult for users. 
[0006] Therefore, a need exists in the industry en- 
hanced telephony using a digital multimedia protocol. 
[0007] According to a first aspect of the present inven- 
tion, a telecommunications system comprises: a public 
switched telephone system: 

a data network; 

interface circuitry coupled between said public 
switched telephone system and said data network 
for translating between analog voice signals and a 
stream of packetized voice signals; and. 
circuit circuitry coupled to said public switched tel- 
ephone network and said data network to control 
communication within and between said public 
switched telephone system and said data network. 

[0008] According to a second aspect of the present 
invention, a service control point for use with a multime- 
dia communication protocol comprises: 

a database; 

a database manager coupled to said database; 



a programmable execution unit coupled to said da- 
tabase manager; and, 

a language sender coupled to th programmable ex- 
ecution unit to communicate with applications exe- 
5 cuted on client terminals coupled to said language 
server via a data network. 

[0009] The invention provides significant advantages 
over the prior art. First, the use of a programmable serv- 
ice logic execution environment (SLEE) in the network 
devices provides for rapid development and deployment 
of products and for flexible implementation of services. 
Second, the invention can be used to gain control of tel- 
ephone calls, even those originating and/or terminating 
on the PSTN, in a digital domain. One particular embod- 
iment of the capability would be in conference calling, 
where callers could control the conference via a web 
browser. This would enable callers to have private con- 
versations with another conference caller, and so on, 
while the conference was ongoing, even if one or more 
of the participants was connecting through the PSTN. 
The sen^ices are seamless to the users, who have the 
same functionality whether independent of whether 
lines of communication originate or terminate on the In- 
ternet or the PSTN. Third, telephony services can be 
initiated via JAVA applets (or a similar software struc- 
ture, which is preferably processor independent) which 
can enhance and simplify telecommunications services 
to users. 

[0010] Examples of the present invention will now be 
described in detail with reference to the accompanying 
drawings, in which: 

Figure la illustrates a block diagram of an IN (intel- 
ligent network) controller coupled to a network, 
such as the Internet, and the PSTN; 
Figures 1b and 1c illustrate functional block dia- 
grams of an SCP; 

Figure 2 illustrates a functional block diagram of a 
gatekeeper; 

Figure 3 illustrates a functional block diagram of a 
gateway; 

Figure 4 illustrates a block diagram of a telecommu- 
nications system using the gatekeeper and gate- 
way of Figures 2 and 3; 

Figure 5 illustrates a functional block diagram of an 
ISN device; 

Figure 6 illustrates a functional block diagram of an 
IP device; 

Figures 7a-d illustrate a flow diagram of a call center 
application with associated browser screens; and, 
Figure 8 illustrates a function block diagram of an 
SMS. 

[0011] Figure 1a illustrates a block diagram of a tele- 
communications network, where intelligent network (IN) 
services can be applied to both a network, such as the 
Internet, and the public switched telephone network 
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(PSTN), including both wireline and wireless services. 
In Figure la, the PSTN and the Internet, or other data 
network (hereinafter Internet/Data Network 6) are cou- 
pled via a gateway 7, such as a H.323 interface or other 
suitable interface. An IN controller 8 is coupled to both 
the Internet/Data Network 6 and the PSTN. The IN con- 
troller 8 is coupled to the Internet/Data Network 6 by a 
TCP/IP or other suitable connection and to the PSTN by 
an SS7 or other suitable connection. 
[0012] The architecture shown in Figure la can pro- 
vide enhanced services to both the Internet/Data Net- 
work 6 and to the PSTN. The IN Controller 8 provides 
programmable services to both the Internet/Data Net- 
work 8 and the PSTN (and to communications between 
the two) using asynchronous messaging with a pro- 
grammable state machine, and a service logic execution 
environment (SLEE). As described in greater detail be- 
low, this architecture provides intra-PSTN communica- 
tions, intra-lnternet/Data Network communications and 
inter-PSTN-Internet/Data Network communications 
with enhanced functionality which is seamless and 
transparent to the users. The IN Controller 8 allows IN 
services to be applied to the Internet, and provides en- 
hanced services to the PSTN by controlling operating 
on the bearer channel of the PSTN while it is packetized. 
[0013] Figure 1b illustrates a functional block diagram 
of a preferred embodiment of a sen/ice control point 
(SCP) 10 used in conjunction with an H.323 protocol, or 
other multimedia communication protocol. The SCP 10 
comprises a SLEE 1 2, database manager 1 4, Web serv- 
er 1 6 and a JAVA server 1 7 and a Domain Name server 
18. The SLEE sends and receives information via a 
standard TCAP (Transaction Capabilities Application 
Part ) message over SS7 (Signaling System 7) line 20 
and via a TCAP message over TCP/IP line 22. The 
SLEE 1 2 communicates with the database manager 1 4. 
Web Server 16 and JAVA server 17. The Web server 16 
and JAVA server 17 communicate with the database 
manager 14 and the domain name server 18. The Web 
server 16 and JAVA server 17 also communicate with 
browser (communication) software 26 over the Intemet/ 
Data Network 6. 

[0014] In operation, the functional block diagram of 
Figure 1 can be implemented on one or more comput- 
ers, such as SUN Solaris computers. The database 
manager, could be, for example, the SYBASE database 
manager. The SLEE 12 is preferably a programmable 
SLEE. Programmable SLEEs are discussed in detail in 
U.S. Ser. No. 08/917,674, entitled "System and Method 
for Communicating Transaction Capabilities Application 
Part Information" to Lin et al, filed August 21 , 1 997 and 
U.S. Ser. No. 08/918,693 entitled "System and Method 
for Implementing Transaction Capabilities /application 
Part Communication Protocol" to Lin et al, filed August 
21, 1997, both of which are incorporated by reference 
herein. The U.S. Ser. Nos. 08/917,674 and 08/917,693 
patents relate to a programmable TCAP SLEE. A pro- 
grammable ISUP/TCAP SLEE is described in U.S. Ser. 



No. 09/317,347, filed May 24, 1999, entitled "AIN/IN 
SSP Extension Product" to Stevens et al (based on pro- 
visional application Ser. No. 60/086,971, entitled "AIN/ 
IN SSP Extension Product" to Stevens et al. filed May 
s 28, 1 998), which is also incorporated by reference here- 
in. 

[0015] The purpose of the SLEE is to execute previ- 
ously created service logic programs (SLPs). The SLP*s 
provide telephony sen^ices, which can be initiated 

10 through the Internet using JAVA applets. A programma- 
ble SLEE uses message definition files which define all 
available messages in an editable file. The message 
definition files can be easily modified to accommodate 
modifications and additions to a protocol. In U.S. Ser. 

IS No. (provisional application Ser. No. 

60/086,971), referenced above, the SLEE uses both a 
TMD file (TCAP message definition file) for messages 
received in TCAP and an IMD file (ISUP message def- 
inition file) for messages received in ISUP. 

20 [0016] The combination of a programmable TCAP 
SLEE 12 and a database manager 14 is sold as the IN- 
FUSION SCP by DSC Communications Corporation of 
Piano, Texas. 

[001 7] The Web server 1 6 and JAVA sen/er 1 7 could 
25 be implemented on the same computer as the SLEE 12 
and/or the database manager 14, or could be imple- 
mented on a computer connected to one or more other 
computers performing the tasks of the SLEE 1 2 and the 
database manager 14. In an alternative embodiment 
30 shown in Figure 1c, the Web server 16 is remote from 
the computer hosting the JAVA Server 17, and is con- 
nected to the JAVA server 1 7 over a TCP/I P connection. 
[0018] The purpose of the Web server 16 is to com- 
municate with client browser software and to service re- 
35 quests for information transfers from the browser soft- 
ware. Several companies, such as MICROSOFT Cor- 
poration and NETSCAPE Communications Corporation 
provide Web Server software for a variety of computer 
platfomns. 

40 [001 9] The JAVA sen/er 1 7 manages sockets to com- 
municate with the JAVA applets running on the client 
browsers 26. It should be noted that while the present 
invention is discussed in connection with JAVA as a pro- 
gramming language used to convey infomnation be- 

45 tween the client browsers and a telecommunications de- 
vice (in this case and SCP), other languages, either cur- 
rently available or later developed, could also be used. 
[0020] The domain name server 18 is a dynamic da- 
tabase which can be updated over the Internet/Data 

50 Network 6 to provide enhanced services. Some of these 
services are described in U.S. Ser. No. 09/201 ,460, en- 
titled "Method and Apparatus for Dynamic Domain 
Names" to Weser et al, filed November 30. 1 998 (based 
on U.S. Ser. No. 60/067,231, filed December 3, 1997), 

ss in U.S. Ser. No. 09/201 ,248, entitled "Digital Phone Sys- 
tem" to Weser et al, filed November 30, 1 998 (based on 
U.S. Ser. No. 60/067,233, filed December 2. 1997), and 
in U.S. Ser. No. 60/096,487, entitled "Method and Ap- 
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paratus for a Dynamic ILS', to Lee Jr. at al. filed August 
14, 1998, all of which are incorporated by reference 
herein. 

[0021] The association between an IP address and a 
name in the dynamic domain name sender 18 may 
change based on any number of parameters. One such 
parameter would be time of day An on-line catalog com- 
pany, for example, may direct orders during morning 
hours to a first web site with a first physical address and 
direct calls during afternoon hours to a second web site 
with a second physical address. 
[0022] Intelligent processing of a domain name could 
be particularly useful in conjunction with digital phones 
which allow audio (and sometimes video) to be passed 
over an Internet connection. A digital phone connection 
over the Internet passes audioA/ideo data packets be- 
tween two or more IP addresses. Digital phone connec- 
tions could be used in a number of commercial settings, 
such as on-line catalog services, where the customer 
may need to talk to a representative. The SCP 1 0 could 
direct a digital phone connection to one of a number of 
available service representatives at various locations. 
The digital phone connection could be based on time of 
day. current load, or other parameters, such as the us- 
er's ISP or local exchange carrier. This would allow a 
representative to work out of various locations, including 
for example, his or her house, with the SCP 10 directing 
the digital phone connections to the proper site. 
[0023] Another parameter which could be used in 
processing IP addresses Is the location of the request- 
ing user. The IN Services could look up the address of 
a requesting user and connect the user to specific home 
page or digital phone based on the address. For exam- 
ple, a pizza chain may have a nationwide number. Once 
called, the dynamic database determines an IP address 
based on the ANI (automatic number identification) of 
the call, then uses that address to set up a digital phone 
connection with the location nearest the user. 
Other parameters which may be used to determine an 
IP address from the dynamic domain name sender 18 
include time, day of week, the user's telephone number, 
and other user profile information, such as age, gender, 
income and so on. Multiple parameters may be used in 
determining the IP address associated with a dynamic 
domain name. 

[0024] It should be noted that non-dynamic domain 
name servers, of the type typically used in the Internet 
to look up domain names, may cache addresses from 
the dynamic domain name server 18, which could alter 
the functionality of the dynamic nature of the dynamic 
domain name server 18. In order to prevent caching by 
other domain name servers, the dynamic domain name 
sender 18 could pass a persist nee parameter ("time to 
live" or "TTL") equal to '0" along with the IP address. 
[0025] In operation, the SCP 10 is seen as a typical 
IN (intelligent network) capable SCP by the PSTN 
through TCAP over SS7/C7 connection 20. Further, the 
SCP 10 can communicate with other devices over the 



connection 22, through SLEE 12. Thus, if a PSTN de- 
vice requires sen^ice information from the SCP 1 0, it can 
retrieve it from database manager 14 through SLEE 12 
as usual. 

s [0026] Other devices may obtain information from the 
dynamic domain name server 18 (and the database 
manager 14) from SCP through connection 22. In the 
illustrated embodiment. SLEE 12 communicates in the 
TCAP protocol. If communication using other protocols 
is desired, translation software may be added to allow 
communication with other protocols. For example, using 
a programmable TCAP SLEE 12, an ISUP-to-TCAP 
converter could be used to allow communication with 
ISUP devices. The converter would add TCAP headers 
to incoming messages and strip TCAP headers from 
outgoing messages. This would allow an existing pro- 
grammable message interface, such as the one found 
on the DSC INFUSION product, to be used in the SCP 
10. Alternatively, SLEE 12 could be capable of commu- 
nicating in a number of different protocols, similar to the 
SLEE discussed in connection with U.S. Ser. No. 
60/086,971 , referenced above. 
[0027] Figure 2 illustrates a gatekeeper device 30, 
which is based on the architecture SCP 10 of Figures 
lb and 1c, In an H.323 network, a gatekeeper has four 
primary functions. First, the gatekeeper performs ad- 
mission control; i.e.. it determines whether or not a de- 
vice can originate or temninate a call. Second, the gate- 
keeper performs bandwidth control, which is defined in 
the RAS (Registration. Admission and Status) specifi- 
cation. Third, the gateway performs address translation 
from LAN aliases for terminals and gateways to IP or 
IPX addresses (also defined in the RAS specification). 
Fourth, a gatekeeper oversees all terminals, gateways 
and MCUs (multipoint control units) within its zone (re- 
ferred to as a Gatekeeper Zone). 
[0028] The gatekeeper 30 shown in Figure 2 is similar 
to the SCP 10 shown in Figures lb and 1c, but it adds 
an additional interface, UDF (user defined function) 
MSG interface 32. A UDF MSG is a user<iefined SIB 
(sen^ice independent building block) which, in this case, 
handles control messages of the H.225 and H.245 pro- 
tocols specified under H.323. The UDF MSG interface 
is connected to a ULS (universal locator service) 34 
through a 225/RAS channel 36 and to one or more gate- 
ways 40 (described in greater detail in connection with 
Figure 3) through RAS channel 38. 
[0029] The ULS is software operated by a network 
provider in order to log in users with the appropriate pa- 
rameters. This software communicates directly with an 
Internet locator service of a server. The gatekeeper 30 
registers permanent IP addresses on the Internet/Data 
Network 6 when the user first accesses the network and 
registers dynamically assigned IP addresses with each 
dial up session (since the user may be assigned a dif- 
ferent IP address with each dial up session). 
[0030] In operation, the gatekeeper, in addition to its 
required and optional services under the H.323 stand- 
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ard can also function to generate conn ctions between 
digital phones, between PSTN phones and digital 
phones, and between PSTN phones using the informa- 
tion in the dynamic DNS 18 as described in connection 
with Figures lb and 1c. It should be noted that while the 
gatekeeper 30 of Figure 2 is shown incorporating both 
a Web server 1 6 and a JAVA server 1 7. it could similarly 
be configured with only a JAVA server 17 as shown in 
connection with the SCP of Figure lb. 
Figure 3 illustrates a gateway 40. A gateway is a termi- 
nal that interfaces between networks, for example, be- 
tween an H.323 network and the PSTN. In the illustrated 
embodiment, gateway 40 provides an interface point to 
the PSTN through ISUP connection 42 for call control 
and T1 connection 44 for analog voice information. IS- 
UP/SS7 connection 42 is coupled to an ISUP MSG in- 
terface 44, which is coupled to SLEE 12. SLEE 12 in- 
cludes a UDF MSG interface 46 which is coupled to 
Voice-over-IP (VoIP) boards 48 along with the T1 line 
44. VoIP boards 48 include a control section 48a which 
receives H. 225/245 commands from the SLEE 12 
through the UDF MSG interface 46. SLEE 12 is also 
coupled to a database 50. 

[0031] The VoIP boards 48 are DSP (digital signal 
processor) boards which translate between analog 
voice signals on the T1 line and packetized (IP) audio 
signals on the Internet/Data Network 6 under control of 
the control signals from the SLEE 12. The VoIP boards 
48 can also send H.323 messages to the gatekeeper 30 
and to other H.323 devices. VoIP boards are available 
froma variety of vendors, including DIALOGIC Commu- 
nications Corporation. 

[0032] In operation, the gateway 40 provides an inter- 
face point to the PSTN through ISUP and bearer chan- 
nels, ISDN lines or the ATM backbone network. The ba- 
sic call state model (BCSM) is contained within an SLP 
to be executed on the gateway's SLEE for both the ISUP, 
ISDN or ATM side and the H.323 side of the call. Mes- 
sages from the ISUP/SS7 connection 42 are received 
by the ISUP MSG interface 44 (not necessary if the 
SLEE can receive ISUP signals directly) which wraps 
the messages in a TCAP header and passes the mes- 
sages to the SLEE. Similarly, when outbound messages 
are sent from the SLEE 12 to the ISUP/SS7 channel, 
the ISUP MSG interface strips the TCAP headers. 
[0033] On the H.323 side, the UDF MSG interface 46 
strips the TCAP header information from outbound mes- 
sages and re-encodes the messages using PER 
(Packed Encoding Rules). Inbound messages also pass 
through the UDF MSG interface 46, which changes the 
message from PER to BER (Basic Encoding Rules) en- 
coding prior to sending the message to the SLEE 12. 
[0034] Figure 4 illustrates a simplified block diagram 
of a communications system where the PSTN and an 
Intemet/Data Network 6 are coupled to gateway 40. 
along with gatekeeper 30. Gatekeeper 30 is also cou- 
pled to other H.323 devices 52. In this embodiment, us- 
ers can create a communications channel between any 



combination of PSTN and H.323 devices (i.e., PSTN-to- 
PSTN. PSTN-to-H.323. or H.323-to-H.323). Further, 
multipoint communications between any combination of 
devices is supported. 

s [0035] For example, a user with only a PSTN device 
(i.e.. a telephone) may call a number which is associated 
with a digital phone. This number would be sent in the 
PSTN to connect to gateway 40. Upon receiving the call, 
the gateway would be supplied with an ISUP message 

10 including the number called (destination number), the 
calling party number and charge number. The gatekeep- 
er 30 would proceed to determine the IP address with 
which to form a connection. In this example, it wilt be 
assumed that the caller dials a number associated with 

IS a particular vendor, such as 1 -800-FLOWERS. After 
registration and admission, the gateway 40 sends a 
message along with the destination number to the gate- 
keeper 30, requesting a look-up of the associated IP ad- 
dress. The gatekeeper 30 replies with routing informa- 

20 tion (an IP address and routing permission) to complete 
the call. As described above, the routing information de- 
termined by the gatekeeper 30 may be dependent upon 
a number of factors, including, for example, time of day 
day of week, calling party number, destination number, 

25 and available operators for this service. 

In an altemative method of connecting to a digital phone, 
the caller dials the number associated with gateway 40. 
The destination number does not indicate the final des- 
tination; once connected to the gateway 40. the user di- 

30 als a second number indicating the destination. The 
gateway 40, after registration and admission, passes 
this number to gatekeeper 30, which determines the IP 
address associated with the destination. 
[0036] Figure 5 illustrates an ISN (integrated service 

35 node) 60 for PSTN to PSTN communications. A first IS- 
UP-to-TCAP translator 62a is coupled to an ISUP con- 
nection of a PSTN switch and a first VoIP board 64a is 
coupled to an associated T1 line. A second ISUP-to- 
TCAP translator 62b is coupled to an ISUP connection 

40 of a PSTN switch and a second VoIP board 64b is cou- 
pled to an associated T1 line. A router 66 is coupled to 
the H. 323 side of the Vol P boards 64a and 64b. and also 
to SRF (service resource function) boards 68a-b and 
SCP 10. SCP 10 is also coupled to SRF boards 68a-b 

45 and to the ISUP-to-TCAP translators 62a-b. 

[0037] In operation, when a connection is made, the 
voice signals from the bearerchannel (T1 line) are trans- 
lated into a stream of data packets by the corresponding 
VoIP board 64. The connection can be made either by 

50 passing the audio packets through the router to another 
VoIP board or by routing the packets through the router 
66 backto the originating VoIP board. In either case, the 
packets are translated back into analog voice signals on 
the associated T1 line. 

55 [0038] While the voice signals are packetized, how- 
ever, the SRFs may control the data stream to play an- 
nouncements, collect digits, perform voice recognition 
(identification), speech totext conversion, text to speech 
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conversion, transfer packets to voicemail servers, per- 
form facsimile store and forward, and other functions 
normally associated with an SRR The SCP 10 can con- 
trol the connections as discussed in connection with Fig- 
ure 1. In the illustrated embodiment the SCP 10 per- 
forms the BCSM functions and controls the SRF accord- 
ing to one or more SLPs executed in the SCP's SLEE. 
[0039] Figure 6 illustrates an IP (intelligent peripheral) 
70, which can be used in connection with the PSTN and 
H.323 network. The IP 70 includes an ISUP-to-TCAP 
translator 72 coupled to an ISUP connection from the 
PSTN and a VoIP board 74 coupled to a corresponding 
T1 line. The ISUP-to-TCAP translator 72 is coupled to 
an SCP 10. The SCP 10 is coupled to an SRF 78. The 
VoIP board 74 and the SRF are coupled to a router 76, 
which may be coupled to other H.323 devices 79. 
[0040] In operation, calls are transferred to the IP 70 
as they would be in a normal PSTN scenario. The bearer 
channel is digitized and IP functions are added/re- 
moved/analyzed as packets, then decoded and placed 
on the bearer channel again. The call is then released 
back to the PSTN. The IP 70 can be concurrently used 
by an H.323 network at the same time. The SRF can 
perform a number of functions on the packetized infor- 
mation in the bearer channel, including playing an- 
nouncements, collecting digits from tones, performing 
voice recognition (identification), performing speech to 
text conversion, performing text to speech conversion, 
transferring packets to voicemail servers, performing 
facsimile store and forward, and other functions normal- 
ly associated with an SRF. 

[0041] Figures 7a-d illustrates a call center applica- 
tion which could be performed using the SCP 10 of Fig- 
ure 1. This application is useful for commercial services 
over the Internet, or other data network, where custom- 
ers can request digital phone connection to operators of 
a vendor. The IP addresses associated with the opera- 
tors will change over time as operators start and stop 
work. Further, the available operators will change during 
the day as operators become busy with customers, take 
breaks and so on. The SCP 10 manages the connec- 
tions between customers and operators as efficiently as 
possible. 

[0042] The operator begins the login process by re- 
questing the login page from the web server via the In- 
ternet This can be accomplished by entering an Internet 
address for the page. As sample operator login page Is 
shown in Figure 7b, with input fields 200 and 202 for an 
operator name and password, and a submit button 204. 
The operator completes the login page by entering his 
or her name and password and presses the submit but- 
ton. A JAVA applet sends the data from the form to the 
SCP 10, either directly (If the web sender 16 and JAVA 
sen/er 17 are at the same site) or via a relay at the web 
server (if the web server 16 is at a different site, in order 
to comply with JAVA security constructs). Upon receiv- 
ing the data from the login fonn, the SCP 10 initiates 
operator-login service logic shown in blocks 90 and 92. 



The JAVA server 17 opens a socket and stores the data 
in the database 14 of the SCP 10. In block 92, the op- 
erator service logic begins. The SLEE 12 reads the op- 
erator data from the database in block 94 and validates 

s the operator. Assuming a proper name and password 
were entered by the operator, a confirmation page is 
sent to the operator in block 96. which monitors that op- 
erators status. A sample confirmation/status page is 
shown in Figure 7c. In this embodiment, there are three 

10 buttons to allow the operator to indicate his or her 
present status: (1) Customer, for when the operator is 
busy with a customer, (2) Break, for when the operator 
is not with a customer but is temporarily unavailable and 
(3) Available, for when the operator is ready to receive 
a call from a customer. The active button, in this case 
the "Available" button, is colored to indicate the current 
status to the operator. Other interfaces, with different in- 
put graphics and different status levels could be used in 
place of this screen, as would be known to one skilled 

20 In the art. Whenever a status button is pressed, the data 
is stored in block 98. In block 102, control is handed to 
the UDF Listener 105. The UDF SIB 98 passes the cor- 
relation ID of the operator back to the JAVA server 17 
through the UDF Listener 105. The UDF Listener 105 

2S monitors different threads (multiple operators may be si- 
multaneously running the service logic). In block 103 
and 104, the JAVA sender 17 collects data from the da- 
tabase and sends confirming information back to the op- 
erator. 

30 [0043] Similarly, a customer can request a form page 
from a vendor via the Internet. For example, a user may 
be browsing a vendor's on-line catalog and wish to dis- 
cuss a product with a customer service operator A sam- 
ple customer form page is shown in Figure 7d. Once the 

35 form page is completed and submitted by the customer, 
the JAVA applet on the customer's computer sends the 
data to the JAVA server 17 of the SCP 10, directly or 
indirectly, along with other information, such as the cus- 
tomer's IP address and browser type. 

40 [0044] The JAVA server 1 7 opens a socket to receive 
and store the data in block 1 06. The vendor service logic 
starts in block 108, In block 110, the SLEE opens the 
database 14 and validates the vendor information in 
block 112. Assuming this is valid, the SLEE 12 collects 

45 the customer IP address, browser type and data from 
the fomn. In block 114, the assign operator routine be- 
gins, where the SLEE determines an active available 
operator. In block 116, the database is updated to reflect 
a busy operator, the start-time, and so on. In block 118, 

50 the UDF SIB is used to pass the correlation ID back to 
the JAVA server. In blocks 1 20 and 1 22, the JAVA sender 
17 reads the database 14 and contacts the chosen op- 
erator with data concerning the customers IP address, 
browser type and form data. 

55 [0045] From this point, the operator can initiate a di- 
rect Intemet connection with the customer via an appro- 
priate conferencing package, such as NETSCAPE 
CONFERENCE or MICROSOFT NETMEETING. When 
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the call is complete, the operator presses the "Available" 
button to update the status in block 96. 
[0046] The application described above does not re- 
quire a dynamic DNS. In an alternative architecture, the 
dynamic DNS 18 would be updated from a default mes- 
sage when the first operator logs in. Subsequent oper- 
ators would then be placed in a buffer prior to being ro- 
tate to the dynamic DNS 18. Customer inquiries could 
then be routed directly to operators using generic URLs, 
but without service logic capability associated with the 
customer. This scheme would impose operator actions, 
such as accepting or completing calls, to update oper- 
ator status. However, multiple messages from a custom- 
er to the same operator would be more difficult to sup- 
port. 

[0047] Figure 8 illustrates an SMS 130 (service man- 
agement system) to provide remote service manage- 
ment and provisioning functions by the OSS (operation 
support services). The SMS 130 is coupled to a redun- 
dant pair of SCPs 10, The SMS 130 includes a PSTN 
SMS 132 coupled to a master database 134. A web 
server 1 36 is coupled to the Internet or to another data 
network and to the master database through database 
connectivity software 138, such as JCONNECT from 
SYBASE, INC, A replication server 1 38 is coupled to da- 
tabases 14 of two redundant SCPs 10. The PSTN SMS 
is also coupled directly to the databases 14. 
[0048] In operation, the master database 134 could 
be modified through the PSTN SMS or through the web 
server 1 36. The replication server copies changes made 
to one of the databases 1 34 or 1 4. to the other databas- 
es, so that all databases are in sync with one another 
The SMS 130 allows users to provision and configure 
services via the Intemet. For example, telephone cus- 
tomers could add/delete/modtfy services over the Inter- 
net without intervention by telephone company or ISP 
personnel. Further, telephone company and ISP per- 
sonnel could perform service modifications over the In- 
ternet, providing more sophisticated HTML (hypertext 
markup language) and JAVA interfaces and allowing 
more personnel to work in a variety of locations. 
[0049] The devices described herein provide signifi- 
cant advantages over the prior art. First, the use of a 
programmable SLEE in the network devices provides 
for rapid development and deployment of products and 
for flexible implementation of services. Second, the de- 
vices can be used to gain control of telephone calls, 
even those originating and/or terminating on the PSTN, 
in a digital domain. One particular embodiment of the 
capability would be in conference calling, where callers 
could control the conference via a web browser. This 
would enable callers to have private conversations with 
another conference caller, and so on, while the confer- 
ence was ongoing, even if one or more of the partici- 
pants was connecting through the PSTN. The services 
are seamless to the users, who have the same function- 
ality whether independent of whether lines of communi- 
cation originate or terminate on the Internet or the 



PSTN. Third, telephony services can be initiate via JAVA 
applets (or a similar software structure, which is prefer- 
able processor independent) which can enhance and 
simplify telecommunications services to users. 

5 

Claims 

1 . A telecommunications system comprising: 

10 

a public switched telephone system; 
a data network (6); 

interface circuitry (7) coupled between said 
public switched telephone system and said da- 
IS ta network (6) for translating between analog 

voice signals and a stream of packetized voice 
signals; 
and, 

control circuitry (8) coupled to said public 
20 switched telephone network and said data net- 

work to control communication within and be- 
tween said public switched telephone system 
and said data network. 

25 2. A telecommunications system according to claim 1 , 
wherein said data network (6) comprises the Inter- 
net. 

3. A telecommunications system according to claim 1 
30 or 2, wherein said control circuitry (8) includes: 

a database (50); and. 

a programmable execution unit (12) coupled to 
said database. 

35 

4. A telecommunications system according to claim 3, 
further comprising a language server coupled to the 
programmable execution unit (12) to communicate 
with applications executed on client terminals in 

40 said network. 

5. A telecommunications system according to claim 4, 
wherein said language server comprises a JAVA 
server (17). 

45 

6. A telecommunications system according to claim 4 
or 5, wherein said client terminals execute JAVA ap- 
plets running under browser software , 

50 7. A telecommunications system according to any of 
claims 4 to 6, wherein said language server initiates 
telephony services between the data network (6) 
and the public switched telephone network. 

55 8, A telecommunications system according to any of 
claims 4 to 7, wherein said language server initiates 
telephony services between the nodes on the data 
network (6). 
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9. A telecommunications system according to any of 
claims 4 to 8. wherein said language server initiates 
telephony services between the nodes on the public 
switched telephone network. 

5 

1 0. A telecommunications system according to any pre- 
ceding claim, wherein said control circuitry (8) is op- 
erable to modify said stream of packetized voice 
signals. 

10 

11. A service control point for use with a multimedia 
communication protocol, comprising: 

a database (50); 

a database manager ( 1 4) coupled to said data- is 
base; 

a programmable execution unit (12) coupled to 
said database manager (14); and, 
a language server coupled to the programma- 
ble execution unit (1 2) to communicate with ap- 20 
plications executed on client terminals coupled 
to said language server via a data network. 

12. A service control point according to claim 11, where- 
in said database comprises a domain name sender 25 
(18). 

13. A service control point according to claim 12, 
wherein said domain name server (18) associates 
domain names and network addresses based on 30 
current values of a pre-selected set of parameters. 

14. A service control point according to any of claims 
1 1 to 1 3, wherein said programmable execution unit 
(12) executes service logic programs. 55 

15. A service control point according to claim 14, 
wherein said execution of one or more of said serv- 
ice logic programs by said programmable execution 
unit (12) can be initiated by through the data net- ^0 
work (6) via the language server 

16. A service control point according to any of claims 
11 to 15, wherein said language server comprises 

a JAVA server (1 7) for communication with JAVA ap- ^5 
plet executed on client terminals. 

17. A service control point according to any of claims 
11 to 16, further comprising a web server (16) cou- 
pled to said language server and said client termi- so 
nals. 

18. A service control point according to any of claims 
1 1 to 1 7, wherein said programmable execution unit 
(12) is coupled to one or more universal locator 55 
services for identifying an IP address associated 
with a user. 



19. A sen^ice control point according to any of claims 
11 to 1 7, wherein said programmable execution unit 
(12) is coupled to service resource function boards 
to operate as an intelligent peripheral (IP) device. 

20. A service control point according to claim 19, 
wherein said programmable execution unit (12) is 
further coupled to an ISUP to TCAP translator (62a. 
62b. 72), 
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